As the quality of network telephony systems has improved, there has been a migration of users from the traditional PSTN (Public Switched Telephone Network) to network telephony systems. With the proliferation of the Internet, Internet telephony has enabled distantly located users to communicate with one another using data protocols underlying the Internet. For example, the IP (Internet Protocol) suite along with various signaling protocols has made IP telephony a popular form of network telephony.
The Session Initiation Protocol (SIP) is a signaling protocol that may be used to assist with call set-up, management, and teardown. Other signaling protocols, such as the ITU-T H.323, MEGACO, and MGCP protocols, may also be used to implement various signaling functions. While these network telephony systems have provided advantages in cost and flexibility, certain challenges have arisen. In particular, network telephony systems are expected to meet the same standards of reliability, fault-tolerance, and availability as present in today's PSTN network.
One specific problem that has arisen in IP telephony systems is how to route signaling messages when intermediate nodes fail. Currently, at least two schemes have been used to address this problem: (1) DNS (Domain Name System) name path specifications, and (2) transfers to stand-by servers. In the first solution, as an alternative to using the IP address of a server in the path between a caller and a callee, the DNS name of the server is used. When a server fails, the DNS is notified of the IP address of a back-up server. Future DNS look-ups will point to the back-up server. This solution, however, may be slow to detect failures, and does not work well for distributed DNS server systems. In the second solution, an active server periodically transfers state information to a back-up server. If a failure occurs, the back-up server takes over. This solution is also subject to several shortcomings. In particular, there is no mechanism to inform the next-hop servers about the change to the back-up server. As a result, this second solution typically only works in proprietary environments with provisioning.
Thus, it would be desirable to provide a mechanism for providing fault tolerance in a network telephony system.